ACM SIGSOFT SOFTWARE ENGINEERING NOTES vol 10 no 2 Apr 1985 page 19
https://portalparts.acm.org/1020000/1012621/fm/frontmatter.pdf
The Parable of the Two Programmers, Continued [1]
W. D. Maurer
When we last left our two programmers, Alan and Charles, they had each produced the same program, though in quite different ways. Alan has just been promoted to Systems Analyst as a result of his leadership of a team at his company (AAAA) that produced a 2500-line program. In his new position, he is no longer responsible for maintaining that program. Meanwhile, Charles, after producing an equivalent 500-line program single – handedly for his company (CCCC), has become discouraged and left CCCC for DDDD (Delaware Distributed Data Division).
One year later, and unbeknown to each other as before, our two companies decided that their respective programs needed to be modified and expanded, and, remarkably, in precisely the same ways. The modifications and expansions are expected, by management, to roughly double the size of the program.
At AAAA, the original program took six months to write, using the PQR structured design methodology. Finding a new programmer who is familiar with PQR takes about six weeks. When Edwin is finally hired, he, just like Alan, asks for three more programmers.
He will handle the first major module ; Frank, Gordon, and Howard will handle modules 2, 3, and 4, respectively.
After three months, Edwin ‘ s manager asks for a progress report. He claims to be “on schedule” on module 1. Gordon is also on schedule; Frank is clearly floundering; and Howard is finished module 4 turned out to be unexpectedly easy to fix. Howard has used up considerable amounts of computer time in running exhaustive tests of every conceivable possibility. Once that was done, he turned his attention to module 2 and started work on it himself, independently of Frank. When Frank found out about this, he raised a political stink and got Howard transferred off the project.
Six weeks later Edwin and Gordon declared themselves finished. They immediately started looking at module 2. At this point Frank raised another political stink, but this time he lost and got transferred off the project himself. Two more programmers were hired, but they were immediately assigned to new work, as Edwin’ s manager was being inundated with requests for it.
Edwin and Gordon divided Frank’ s module into two parts and finish it in three more months. The program is now placed under test, and, just as in Alan’s case, the users find a number of bugs and deficiencies. These take four months to correct, rather than two, because there are now only two programmers working on them.
After a total of nearly twelve months has gone by, the production version of the program is complete. Just as predicted, it consists of very nearly 5,000 lines of code. It is just as fussy about the input data format, although now, since so many more types of input are accepted, the data-entry staff all have to go through yet another training course.
Meanwhile, at CCCC, a quite different story is developing. As before, a newly hired entry-level programmer, John, who thinks he is really good, is hired to make the modifications. John is just as fond of Space Invaders as Charles ever was, but is a little more careful about not being caught playing by his manager.
At the end of three months, John announces he has completed the modifications. He submits a program which, wondrously, is just about 1,000 lines of code. The program is tested and immediately produces howls of disappointment. It seems that, on input that was
accepted and processed by Charles’ program, John’s program produces completely different results.
Up to now John had been using only his own generated test cases; he had never used “real” data. A heated meeting ensued. John insisted that his program did what the specifications said. Upon looking at the specifications, as given in Charles’ documentation (about one page of documentation for the entire program – – Charles loved conciseness in all things), it became clear that John had simply misunderstood, from the beginning, what Charles’s program was supposed to do.
John went back for another two months, this time with real test data. The second version of John’s program runs fine on the real test data; the users produce three more real test data runs, and on each one there are discrepancies between John’s and Charles’s output. After another month goes by, the third version is ready, and this time a new user enters the picture. He uses several features of the system that were not exercised in the earlier tests, and uncovers a whole slew of new discrepancies. John offers to try again, but his manager is disgusted and decides to start over. A new programmer, Keith, is hired.
Keith spends a month working with users and defining the exact nature of the problem. After another month goes by, Keith announces a major breakthrough. His manager enters the room, to discover that Keith has translated Charles’original program into assembly language. Sure enough, it runs five times faster than the original. The manager has read somewhere that assembly language programs are very difficult to modify. He transfers Keith off the project and brings in a new programmer, Larry.
Larry is given the voluminous notes that the users worked up for Keith. He spends one day reading them and sets to work. After about ten weeks Larry’s program is ready. It is worse than John’s. Unlike John, however, Larry never claimed that his program followed the specifications. When confronted with obvious discrepancies between his program and the specs, Larry simply smiled and said, “Gee, that’s right; you’re right.” It soon became obvious that Larry could not read English; he could only do things he invented in his own head.
Mike, the best programmer in the shop, is now asked to try his hand. Unfortunately Larry has lost his only copy of the voluminous notes, and Mike tries to re-derive them by going around and talking to six different users, four of whom immediately howl that Mike is treating them with open contempt (and they really are Mike’s intellectual inferiors). The manager, sorely beset, moves Mike back to what he was doing before, and brings in Norman.
Norman is very nice to users, and the manager breathes a sigh of relief. It is now one year later, and Norman is still working, promising “any day now.” Unbeknown to the manager, AAAA finally let Frank go, and Frank started using his middle name, which is Norman, and went to work for CCCC.
AAAA has a 5000-line program which works. CCCC has the original 500-line program, which works, and three expanded 1000-line programs, none of which work, plus Keith’s translation into assembly language. Last week, in order to show at least some progress, Keith’s program was put into production. The users are impressed with the increase in speed, but have long since given up hope that there will ever be any increased functionality.
W. D. Maurer
The George Washington University
Dept. of Electrical Engineering and Computer Science Washington DC 2005 2
The Parable of the Two Programmers — Still More
Tim E. Barrios
I hope the readers of Neil W. Rickert’s story “The Parable of the Two Programmers” did not interpret its moral to be contradictory of software engineering principles. Rather, I feel, that it shows what mis-interpretation of the principles can do. The moral I derive from the parable is that “you get what you pay for” or, in terms of software management, “you get what you measure”.
Judging from its obsession with “lines of code”, Automated measures productivity by and rewards quantity of code. In addition to the management problem, their methodology is very weak since they started coding before Charles (of Consolidated) who, we assume, used little or no formal methodology. Charles spent much more time in pre-coding stages before producing “lines of code” which would have been viewed by the management of Automated as unproductive time due to their productivity measure. Consolidated, on the other hand, instructed Charles to “tackle the job” (solve the problem). With no management interaction, he solved the problem more productively than Automated but was viewed as less productive due to the solution’s lack of both size and complexity.
The mis-understanding about complexity is another interesting issue. Software should certainly not be judged on its complexity (as both managers did) or even simply its lack of complexity. Quality is achieved by minimizing the complexity of the solution in relation to the complexity of the problem at any adjacent levels of abstraction (requirement to design, design to code, etc. ) — the complexity differential. In the case of this problem, whose complexity is the same for both companies, the solution which was less complex (Charles’) is certainly better and would be reflected by the complexity differential attribute of “quality”. The difficulty in the parable is the perception by the management of what quality is (the more complex solution implementer was praised and rewarded).
Each project’s definition of quality, defined by weighting quality attributes, will guide the developers and maintainers in forming the product. In the case of Automated, quantity of “lines of code” and high complexity are apparently weighted heavy in their definition of quality. Charles, with no management direction, perceived quality as a product which performed the desired function (solved the problem) ; he even did it more efficiently than Automated because no one told him, until his review, that his manager measures (pays for) complex, voluminous code.
When reading this story, I was reminded of a rule that I heard while working on a very large development effort: no software project can be done effectively with more than 6 or less than 200 people. The only argument that may support this theory is that maybe the definition of effectiveness (like quality) is defined differently depending on the size of the project and the attitude of the management and, hopefully, the customer and users toward the desired quality of the solution to the problem.
Tim E. Barrios
Software Engineer
Harris GISD Software Operations R1/154 4
505 John Rodes Blvd.
Melbourne FL 32902
Phone 305-242-5396
Maurer, W. D., & Barrios, T. E. (1985). The parable of the two programmers, continued. ACM SIGSOFT Software Engineering Notes, 10(2), 19–22. doi:10.1145/1012621.1012623
[1] The reader is invited to revise the moral that he may have derived from “The parable of the two programmers” (SEN 10, 1 [Jan. 1985]).
